The field of this invention is information systems security, and in particular the regulation of the flow of information to or from a host coupled to a network.
Known firewalls regulate the flow of information by acting as an intermediary between two entities that desire to communicate with each other. Known firewalls typically fall into one or more of the following categories: a packet-header firewall; a proxy firewall and an authentication firewall.
The known packet-header firewall operates on packetized information, where each packet includes a source address, a source port, a destination address, a destination port, a communications protocol identifier (collectively known as “header information”) and a payload. This type of firewall stores a list of rules that specify that a given packet is to be permitted to PASS through the firewall to its intended destination based upon its header information, or else the packet must be blocked (i.e., a DROP or delete action must be performed on the packet.) For example, a rule may state that all packets of the Transmission Control Protocol (“TCP”, see RFC 793, Transmission Control Protocol, Defense Advanced Research Projects Agency, September 1981, <http://www.faqs.org/rfcs/rfc793.html, visited Dec. 26, 1999> from Source Address 102.23.132.4, Source Port 40 to Destination Address 193.2.24.32, Destination Port 41 are allowed to PASS. Another rule may state that all packets from any Source Address, Source Port 80 to any Destination Address, any Destination Port must be DROPPED.
The known packet-header firewall disadvantageously cannot detect and block packets that have the correct header information, but that are being sent by a malicious program. Such a malicious program can include a computer virus or Trojan horse in the payload of the packet or packets that the firewall allows to PASS. Another disadvantage of using header information rules is that this technique cannot prevent a trusted person from sending confidential and/or proprietary information through the firewall. This is because such information is in the payload, which is not examined by this known type of firewall. Further, an application that is configured to create and send packets that the firewall permits to PASS can be maliciously altered to circumvent the rules of the firewall so that illicit information can be sent and received in spite of the controls implemented by the firewall. For example, a firewall rule that prohibits the transfer of files, but allows the sending of e-mail, can be circumvented by sending files through a pseudo-e-mail application that superficially uses an e-mail protocol. In this way, confidential and proprietary files may be sent surreptitiously without being detected and blocked by the firewall.
Known firewalls that base a PASS or DROP decision upon header information alone can be of limited usefulness, because the security policy by which the firewall operates dictates that data be PASSed or DROPped based upon information not available in the header information. For example, some frequently used applications, such as the File Transfer Protocol and H.323 can negotiate different port numbers for communicating on a session-by-session basis. This disadvantage is mitigated by known proxy firewalls. A known proxy firewall examines the contents (the payload) of a packet (and not just its header information) to obtain further information about the nature of an attempted communication. The proxy firewall can therefore make a decision to PASS or DROP a packet based upon more information than just the header information. But investigating the content of each packet can quickly overwhelm a firewall through which a substantial amount of traffic flows.
The third type of known firewall is the authentication firewall. The authentication firewall only permits information to PASS if the firewall can properly authenticate the sender of the information. An example of this type of firewall is the SOCKS system described in RFC 1928, SOCKS Protocol Version 5, <http://www.faqs.org/rfcs/rfc1928.html, visited Dec. 26, 1999>; RFC 1929, Username/Password Authentication for SOCKS V5, March 1996, <http://www.faqs.org/rfcs/rfc1929.html, visited Dec. 26, 1999>; and RFC 1961, GSS-API Authentication Method for SOCKS Version 5, June 1996, <http://www.faqs.org/rfcs/rfc1961.html, visited Dec. 26, 1999>; and the SOCKS5 product by NEC Systems, Inc. of San Jose, Calif., described at <http://www.socks5.nec.com/, visited Dec. 7, 1999>. For example, when a sender from inside the known authentication firewall (e.g., on an internal network, such as an intranet) wishes to send information to an entity on the outside of the authentication firewall (e.g., to an entity on an external network, such as the Internet), the sender must first authenticate itself to the firewall. In one example, the sender must enter and send the correct user identifier and secret password to the firewall. In another example, the sender must insert a secure token (e.g., a secure smart card) that sends information to the firewall, and then must enter his secret personal identification number (“PIN”), which is also sent to the firewall. The firewall only permits communications between the sender and the external entity after it is satisfied that the user is authenticated, i.e., that the user is in fact who he purports to be. This type of firewall advantageously need not examine the contents of each packet it receives, but disadvantageously provides no protection against malicious acts by a trusted insider. For example, a trusted individual inside the firewall can maliciously authenticate himself to the firewall only to transfer confidential and proprietary files without authorization to an entity on the external network, through the firewall.
Known firewall systems are thus forced to tradeoff efficiency for the ability to implement a more detailed security policy across a full range of protocols and applications. No centralized firewall system can fully embody both of these desirable properties.